Finding Your Groove

Building competence and ability to execute#

Your job as a junior developer is to build competence and the ability to execute. It’s more important that you ask good questions than that you always have answers. Over time, you will learn to have an informed opinion that your employers rely on.

This is your time to not know anything#

Better you ask now than a year from now. Say “I don’t know” or “Can you elaborate what you mean?” frequently. Take “My door is open” literally. Indulge your curiosity. Ask questions the smart way. They have to teach you— in fact, some senior developers are evaluated on their ability to explain things simply and to mentor juniors. Return the favor by taking lessons to heart.

📝 Note: See the Lampshading chapter for more tips on how to turn ignorance into power!

Pair programming#

A powerful and subtle way of asking for help is asking to pair program with your mentors and peers. It may feel awkward at first, but there are always subtle tips and tricks to pick up from closely watching how your coworkers solve problems, and they can understand where you make mistakes and give more context than normally available in a code review.

Example 1: Pivotal#

Knowledge transfer by osmosis is incredibly powerful and productive. This practice is so beneficial that some companies (like Pivotal) have adopted the policy of always pair programming as part of an Extreme Programming practice.

Example 2: MapReduce and TensorFlow#

The top two engineers at Google Jeff Dean and Sanjay Ghemawat paired all the way from their time at DEC to creating MapReduce and TensorFlow.

You don’t have to go that far, but in general, most junior developers benefit tremendously from “pairing” with colleagues. You should request pair sessions if your company doesn’t yet make it a norm.

Start emulating your coworkers#

Once you have a good sense of how your coworkers think and work, you can actually start “emulating” them in your head. When approaching a task, you can ask, “What would a COWORKER do?” At a prior job, we had a great code review feedback grading system, but I found that we could reduce the latency of code reviews by preemptively reviewing my own code with concerns that coworkers were likely to raise.

Review your old work#

If your team wants more ideas for effective code review, Google’s Code Review guidelines are public. As you gain more experience, you should also review your old work and think about how you can comment, document, and design your code better for your own future readability and extensibility.

Work on your problem-solving skills#

Work on your problem-solving skills, and understand that we all have struggled like you are right now. Take some time to learn how to use a debugger. Debuggers are very beneficial when navigating new, undocumented, or poorly documented codebases or debugging weird issues. Do not give up if Stack Overflow or an issue on GitHub doesn’t have an answer. Sometimes, all you need to solve your problem is to take a short break or try to explain it to a rubber duck.

Understand how to help them help you#

Saying “I am stuck, but I have tried X, Y, and Z. Do you have any pointers?” to your lead is much better than saying, “This is beyond me.” When writing up an issue or bug report, help them help you by writing a good title, providing key details upfront, including error messages and environment/package versions without asking, providing a minimal reproduction of your issue, and explaining what you’ve tried and what you expected.

If screenshots speak a thousand words, then recording gifs and quick explainer videos can speak volumes. See StackOverflow’s guide on “How do I ask a good question?” for more.

A few developers fall prey to the opposite problem. Instead of lacking confidence, they assume too much confidence. The Dunning-Kruger effect is real; remember that you don’t know what you don’t know. It’s easy to come in and feel like everyone before you were idiots, everything is an unacceptable technical debt, and you know how to fix everything in theory.

Chesterton’s Fence reminds us that when confronting things we don’t understand, we should understand the reasoning behind them first. Don’t fall in love with your code; don’t fall in love with your solutions. You might read clean code and want to apply it to everything, only to find that it’s not helpful in the real world.

You will have to learn a lot from your senior colleagues, while at the same time understanding that they can be wrong too. I once had a boss tell me, “React is object-oriented because it uses classes,” and realized how poorly he understood React. You will need to develop the judgment, understanding, and persuasive skills to navigate these confusing early days.